Cause 1: Target database table content

If errors relate to tables, they probably are caused by the tables content in the target database.

If the referential integrity of the target data does not conform to the specifications in the source database, the corresponding table relations cannot be updated.

If columns are flagged NOT NULL, then records with NULL values in such columns will cause the table update to fail. Likewise the update of table checks can fail if their conditions are not satisfied by the target database content.

Errors reporting possible data loss can occur if columns are reduced in size or precision. If you don't mind the possible data loss you can instruct SQLSchema to ignore this kind of error by selecting the "ignore possible data loss with field changes" option.

Cause 2: forward references

Updates of tables, views, procedures, functions and triggers can fail because they contain forward references. If a procedure references a function that has not yet been created or updated, it cannot be compiled correctly and will thus fail. In some cases SQLSchema corrects such forward reference errors automatically.

The remaining errors can ususally be resolved by repeating the database synchronization run one or more times. Future versions of SQLSchema will handle forward references in a more efficient manner.

Cause 3: Selective update

Errors may occur if you have filtered the objects for database comparison, or did not select all update scripts to execute.

Q: Why does SQLSchema still report schema differences after a successful synchronization?

SQLServer keeps informations about a view's columns in the syscolumns table. If some underlying table or view is changed, those changes will not be reflected in the syscolumns table until this view is recompiled. In addition to the view's definition, SQLSchema compares the information in the syscolumns table. If they are not the same in the source and target database the view is flagged as different.

In order to make the information in the syscolumns table conform to the view definitions you can use the "Recompile Objects" function in SQLSchema. If you have views referencing other views in your database repeated execution of "Recompile Objects" may be necessary to completely update the syscolumns information for all views.

We suggest that you ensure a correct syscolumns information in your source database before attempting a synchronization (it is a good idea to keep this informations up to date anyway).

Future versions of SQLSchema will handle view recompilation in a more efficient manner.

If you are sure your source database syscolumns information is correct, then repeated snychronization runs will resolve those differences. You can also "Recompile" your source and/or target database(s) to make them report as identical.

In some cases different source and target SQL Server versions or Service Pack versions may produce differences that cannot be resolved.